1. Field
The teachings herein relate, generally, to software-related security and, more particularly, to authenticating software by determining whether software operating on a computing device has been tampered with or altered.
2. Description of the Related Art
Most known Internet web services require end users to authenticate themselves to a particular computing device, referred to herein, generally, as a “control server.” The control server grants users access to information, data or services that may be financial or otherwise confidential in nature. Many e-banking or e-payment services protection is based on an assumption that users are effectively and securely authenticated before the information, data or services are provided to them, and that the financial transaction overall is, therefore, secure.
A “host” device, as referred to herein, includes a computing device that stores information, data or services to which the control server authorizes access. In other contexts, a host device may include a computing device operated by an end-user.
One known and relatively simple form of authentication involves the use of static, i.e., fixed in time, login credentials which the user provides to the control server each time the user requests access. For example, the user submits a username and password and, once validated, the control server grants access. The next time the user requests access, the user submits the same username and password. In such scenario, the security of Internet web transactions relies on the secrecy of the login credentials, which are the only factors guarding against illegitimate use by unauthorized individuals. Unfortunately, the use of static login credentials may be ineffective against, for example, pharming, phishing, sniffing, simple social engineering or brute force attacks, whereby an attacker is capable of guessing or otherwise obtaining login credentials, and may carry out a number of fraudulent transactions before the legitimate user or the Internet web service provider discovers the fraud. Such attacks highlight a weakness of static login credentials, including the decoupling of authentication credentials from the individual, whom they are purposing to authenticate.
The use of static login credentials to access online services that otherwise require strong security assurances is not sufficiently reliable and has, therefore, been mostly discontinued. In place of static login credentials, the use of one-time-passwords has been used, in which each of a plurality of passwords are used to gain access to secured information, data or services, and which are based on one of three methods. One method regards time-synchronization between an authentication server and a software application or device operated by a user to generate the one-time-passwords. A second method regards use of a list of one-time-passwords that are printed on paper and securely kept by the user. A third method regards the use of a portable electronic device, such as a mobile phone, that is operated by a user and provides a second channel besides the Internet for receiving the one-time-passwords generated on the server.
When using an external hardware device, the above-identified first method falls into a general class of two-factor authentication methods, which aims at binding the physical user to the requirements of the authorization procedure. The two-factor authentication method, in addition to the static login credentials, includes use of something that the user possesses, such as a physical device or a token external to a host device. Alternatively, the two-factor authentication may include use of a physical characteristic or trait of the user, and may be obtained using biometric sensors such as via fingerprinting or iris scanning. Due to technological limitations and high costs associated with mass deployments of biometric devices, however, the prevailing choice has until now been to provide users with small hardware tokens or smart devices that the user must have and operate each time the user requests access to secured information, data or services provided on the Internet.
The two-factor authentication may include a tamper-resistant device that stores a user-specific secret, which is required to authenticate a user. For example, a smart card and reader are connected to a host device and used during an authentication procedure. The control server authorizes access to information, data and/or services when the server receives authorization information that is obtained from a user-specific secret stored on the smart card.
Both methods described above rely on a software application (e.g., a software-controlled process executed on a host device) to communicate with the control sever. For example, a banking application executing on a host device may require that a transaction service be performed, in which the control sever may generate a random session key and then protect the session key in such a way that it can be obtained only with the user-specific secret key stored on the smart card. It would appear that only the banking application can access the secret key and that the secret key can never leave the tamper-resistant smart card. It would further appear that the secret can be safely kept and operated by the user and that no one except the legitimate user would be able to complete a transaction securely.
The one-time-passwords method and other two-factor authentication methods described above, however, suffer from the same fundamental weakness. A rogue application, such as developed by a malicious programmer, may be executed on an end user's device or on another device via a remote connection to the end user's device, and can make an identical request to the control server after obtaining all the necessary authentication data from the unaware user. The objective of the rogue application is, typically, only to access sensitive information, such as banking resources, and not to know or otherwise extract the user-specific secret key from the tamper-resistant device. To obtain its goal, the rogue application can simply make the same authentication request to the control server that the banking application would make using the user-specific secret, and thus be able to obtain access to the sensitive resources on the server. Continuing with this example, from the control server point of view, there is nothing to differentiate the bank application's authentication request from that of the rogue application. Once this latter has gained access to the service, it can, at least in principle, operate independently from the bank application and from any further user input.
Remarkably, the above-described weakness applies to virtually all user-based authentication methods, regardless of the respective enabling technology applied to generate and store the secret access credentials. This is largely due to a need for all user-based authentication methods to rely on the trustworthiness of the applications employed to communicate with one or more service providers.
The security of Internet web transactions is, accordingly, dependent on an ability to authenticate executable code that runs on a host device, an issue that falls into the more general category of software security. Providing secure software, for example, in a distributed computing environment presents major problems for software development vendors. Experienced hackers may be able to intercept the distribution or the installation of otherwise secure software and alter its performance in some way. Alterations may include, for example, bypassing automatic licensing checks, inserting malicious computer viruses, and interacting with external computing resources, such as groups of software robots that run autonomously and automatically to achieve various criminal goals (e.g., “botnets”).
Unfortunately, proficient hackers are capable of bypassing even very sophisticated protection techniques. One technique hackers use is to statically analyze and trace the executable code to critical points in the execution sequence and then alter return values to those that are required to gain the vendor's authorization or to modify the application's business logic. By changing the executable code to effectively bypass critical checks, hackers are able to bypass any internal validation requests and to hijack an Internet web transaction after the authentication procedure has been properly completed by the unaware user. Moreover, once software has been modified, a hacker can create a permanent fix by patching the operating system or the executable code itself and then by reinstalling the software on the operating system and even distributing worldwide the hacked software.
Moreover, some sophisticated Trojan applications have the ability to dynamically alter the operation of program code by modifying an image of an application or application code which is resident in the memory of a computing device's operating system. In this way, one or more internal processes performed by executable code may be altered after the modified image is handed over to the operating system. By changing the image of executable code, hackers can bypass all static code defenses including reactive techniques, such as fingerprinting and signature-detection, which are heavily utilized by today's anti-virus programs.
Software vendors have reacted to threats from hackers by applying various techniques, such as source code obfuscation, to complicate the task of analyzing and reverse engineering the executable code. Such defenses, however, can at best slow down the hacking attempts that will eventually succeed given enough time and resources.
Attempts at counteracting software attacks, particularly such as those described above, have spawned the development of integrity-check methods. These methods compare a calculated checksum of a software application's image running in memory against a known checksum of the application. If the two checksum values are different, then the application is deemed to have been tampered with. Unfortunately, this is considered a weak form of tamper detection since an attacker can remove the check in the appropriate context within the software or application. Consequently, any comparison between the two checksums is only useful when the comparison is performed independently of the application's host environment. For example, the comparison should be made on a control sever or an external tamper-resistant device on which the valid checksum had been previously stored. Unfortunately, this method of integrity-checking requires the previous knowledge of the software's respective checksum values in one or more various operating conditions, which may be impossible, or extremely complex and costly to implement. Furthermore, given enough time and resources, it is still possible for a crafty programmer to write malicious software that sniffs and captures all possible checksums required by the integrity-check process and to provide a table or other data source to a rogue application for use during the integrity-check authentication process.
Hence, it is highly desirable to improve prior art methods for authorizing access to data that are securely stored on a control server or on a tamper-resistant device. More particularly, providing reliable and practicable authentication for software applications is of paramount importance in today's global access and service environment, which is presently being fueled by the pervasiveness of the Internet.